Intel® DMI 2.0 Service Provider SDK Version 1.10 for Microsoft Win32* Release Notes

THIS IS A PRODUCTION RELEASE FOR USE UNDER THE TERMS AND CONDITIONS DESCRIBED IN THE LICENSE AGREEMENT.

This document contains information about the above product in these sections:

1. Release Contents
2. Changes from the Previous Release
3. Target Environments
4. Technical Support Information
5. Installation Instructions
6. Operating Instructions
7. Product Release Notes
8. Appendix A: Controlling the Service Provider RPC Functionality

1. DMI 2.0 Service Provider for Windows* and DCE RPC:
   
   
   
   • This includes the Intel DMI 2.0 Service Provider and DCE server.
     
     
   • A local (RPC-less) client is included for Component Interface (CI) and local Management Interface (MI) support.
   
   
2. DMI 2.0 Client for Windows and DCE RPC:
   
   
   
   • Provides remote Management Interface (MI) support through DCE RPC.
   
   
3. DMI 2.0 SDK Support:
   
   
   
   • DMI Intel client front-end Management Interface (MI) API
     This includes libraries (DLLs) and header files.
     
     
   • DMI 2.0 Component Interface (CI) API
     This includes libraries (DLLs) and header files.
     
     
   • Examples
     This includes sample management applications and component instrumentation/event programs.
     
     
   • Documentation
     This includes an SDK reference manual and other documentation for the development tools.
   
   
4. OEM Setup, including:
   
   
   
   • A ready-to-use setup package, containing the DMI 2.0 Service Provider and Client.
     
     
   • A response file to run the setup in silent mode.
     
     
   • An example of how you can invoke this silent setup from other installation programs.

• The Intel DMI 2.0 Service Provider SDK Version 1.10 for Win32 implements a new feature that allows the configuration of the SP and indication server for selected RPC and transport protocols. See Chapter 1 of the SDK Reference Manual for more information. Please note that the reference manual contains information also on the Intel DMI Explorer and development tools.
  
  
• The Intel DMI 2.0 Service Provider SDK Version 1.10 for Win32 implements a new feature that allows the control of the RPC functionality of the Service Provider at startup and during Service Provider execution. For more information, see Section 8 below.
  
  
• The client front-end API was extended in this release of the DMI SDK, to include new functions. You do not have to recompile or re-link existing applications. See Chapter 7 of the SDK Reference Manual for more information.
  
  
• Several Service Provider problems were fixed, particularly in the national language support. See Fixed Bugs in Section 7 below.
  
  
• Improved documentation, including: details on additional client front-end functions in Chapter 7 of the Reference Manual; operating-system specific information added to Chapters 1 and 6 of the Reference Manual; changes to the registry detailed in Chapter 1 of the Reference Manual.

For Windows NT, you must be logged into an account with administrator privileges to install the Service Provider in this SDK.

SDK Installation Known Problems / Issues

• Installing the Intel DMI 2.0 Service Provider SDK 1.0 on top of this SDK causes a problem.
  
  Workaround
  Uninstall the current SDK before installing the Intel DMI 2.0 Service Provider SDK 1.0.
  
  
• If the installation program finds a previous or an old copy of the DMI SDK it does not allow the user to choose the target directory, instead it uses the old one.
  
  Workaround
  Uninstall the previous version and delete the old database file sldb.dmi (you will lose all the old component information), or overwrite the current SDK directory.
  
  
• In some cases in Windows NT, the installation program fails to stop a running Service Provider. This causes the installation program to stop the installation process with an appropriate warning message. This problem is applicable only if you try to reinstall the SDK.
  
  Workaround
  Stop the Service Provider service manually. Click the Services icon located in the Windows NT Control Panel, select the Service Provider service, and click Stop.
  
  
• In Windows NT, the installation program fails to move old installation files that are currently in use to a backup directory. This causes the installation program to stop the installation process with an appropriate warning message. This problem applies only if you try to reinstall the SDK and the target installation directory is located on a different drive from the current installation.
  
  Workaround
  Stop the Service Provider service and its clients manually, or use the same target directory.
  
  
• In Windows 95, the installation program fails to move old installation files that are currently in use to a backup directory. This causes the installation program to stop the installation process with an appropriate warning message. This problem applies only if you try to reinstall the SDK.
  
  Workaround
  Stop the Service Provider and its clients manually.
  
  
• If the installation process is canceled while files are being copied, some files remain from the old installation while others are updated. This may prevent the previously installed SDK from running. On Windows NT there is another side effect: the Service Provider service remains stopped. It must be restarted manually from the Services icon located in the Windows NT Control Panel.
  
  Workaround
  Don't cancel the installation process during the file copy phase.
  
  
• In Windows NT, if the installation process is canceled while files are being copied, the Service Provider Service remains in a stopped state. This may prevent the previous installed SDK from running.
  
  Workaround
  Don't cancel the installation process during the file copy phase.
  
  
• The installation program may leave some temporary files in the temp directory. The temporary files are located in %temp%\~pftw???\*.* and %temp%\_istmp??.dir\*.*
  
  For example c:\temp\~pftw001\setup.ins and c:\temp\_istmp1.dir\_isdel.exe.
  
  Workaround
  Remove those files manually after reboot.

• The uninstall program leaves these directories after uninstall is complete: dmi\win32\bin, dmi\win32\mifdb, dmi\win32\mifs, dmi\win32\mifs\backup, and dmi\win32\backup.? Most of these directories are not deleted since they contain files which are necessary for a second installation. For example, the DMI database, sldb.dmi, is not deleted.
  
  Workaround
  Remove any unnecessary files manually after reboot.

On Windows 95 the Service Provider is registered as a service to be started on Windows boot. This is located in the registry under the path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunService s key = Win32sl

If you don't want the Service Provider invoked on boot remove the key, Win32sl. The installation program installs the Service Provider with the parameters -i -p -r. See the Reference Manual included in this release for more details on Service Provider specifics.

On Windows NT, the Service Provider is created as a service, which has a dependency on the RPC service, RPCSS.

7) Product Release Notes
------------------------------------------

1. DMI 2.0 Service Provider SDK Reference Manual, REFMAN.PDF
   
   
   • Adobe Acrobat* Reader version 3.0 or greater is required to view this file. The viewer is available at no cost on Adobe's home page at http://www.adobe.com/prodindex/acrobat.
     
     
   • When opening this document in Adobe Acrobat Reader, the default magnification causes some graphics to degrade. For optimal viewing, select the Zoom In option from the View menu and set the magnification to 160%.
   
   
2. OEM Setup.
   
   
   • The OEM Setup files are located in %Win32DmiPath%\oemsetup\disk1 (where %Win32DmiPath% is the directory that was chosen during installation).
     
     
   • %Win32DmiPath%\oemsetup\example contains an example of using the silent OEM Setup. To run the example, copy the %Win32DmiPath%\oemsetup\example\setup.ins file to the %Win32DmiPath%\oemsetup\disk1 directory and run setup.exe from this directory. The source code of the example is in: %Win32DmiPath%\oemsetup\example\setup.rul
     
     
   • %Win32DmiPath%\oemsetup\disk1 provides a response file, dmi_sp.iss. When applied to the OEM Setup, it installs the DMI 2.0 Service Provider and the client with the base path C:\DMI\WIN32, or the existing base path if a previous installation exists. No program folder is created. To change the base path: locate the line beginning with szPath= in the [AskDestPath-0] section, and change the path. You can also make the silent install create the Uninstall Intel DMI 2.0 SP SDK v1.10 icon: in section [SdSelectFolder-0], locate the line beginning with szFolder= and change the program folder name. In the same section, locate the line beginning with Result= (immediately below) and change its value from 12 to 1.
   
   
3. DMI 2.0 Service Provider v2.54 (WIN32SL.EXE)
   
   Fixed Bugs (since DMI 2.0 Service Provider SDK Release 1.0)
   
   These bugs, which occurred in the DMI 2.0 Service Provider SDK Release 1.0, have been fixed and no longer occur in this release of the SDK:
   
   
   • DmiFree() causes an access violation when called from an indication callback.
     
     
   • A thread in the DMI SP is activated every minute, making the DMI SP working set greater than it should be.
     
     
   • The DMI SP running in a system connected to a LAN via RAS can return error DMIERR_SP_INACTIVE.
     
     
   • DmiList functions may occasionally return strings in an invalid language.
     
     
   • The Service Provider does not recover from database corruption that occurs on the first start after installation.
     
     
   • Memory leaks occur in DMI SP/Client.
     
     
   • Incorrect parsing of the last default attribute value in a table when the attribute is type date.
     
     
   • Service Provider refuses to install a 1-row table when the last attribute is a key and its value is defaulted.
     
     
   • Service Provider may hang if a local MA is ungracefully terminated.
     
     
   • Service Provider on Windows 95 won't shut down if a CI is left running.
     
     
   • ComponentID installation date attribute reports month/date in reverse order.
   
   [Known Issues]
   
   
   • DMI Service Provider Database (SLDB.DMI) is not compatible with v1.x databases. Database upgrade is not implemented in this version of the Service Provider.
     
     
   • The Service Provider database does not support variables of size greater than 508 bytes. CI instrumented attributes do not have this limitation.
     
     
   • The Service Provider detects duplicate keys in a table at installation time; that is, you cannot install a MIF with a table that contains two rows with the same keys. However, the Service Provider does not check for this condition when the value of a key is set.
     
     
   • The Service Provider does not allow more than 127 keys per group.
     
     
   • Service Provider doesn't guarantee synchronization between indication and completion of the DMI Add / Delete operation for Component, Language and Group entities; that is, an application may receive DmiComponentAdded indication before DmiAddComponent function completion.
     
     
   • Service Provider serializes requests to the component instrumentation on a per-component(ID) basis. This means that an instrumentation application that registers for multiple components may receive overlapping calls. It is the responsibility of the application to serialize calls across component boundaries, as needed.
     
     
   • The Service Provider delivers pending indications even after the event consumer has canceled indication subscription. For example, System B registers to receive indications from System A. After System B unregisters and unsubscribes from System A, System B will still receive all outstanding indications (any indications that are waiting to be processed when the unregister occurs) from System A, but no additional indications. To avoid this situation, ensure that no indications are pending before canceling indication subscriptions, if at all possible.
     
     
   • The DmiGetSubscriptionAddress() helper function may return an address that is not reachable by the indications originator. This can occur only on systems with more than one IP address, when one of these addresses is unreachable from the indications originator system. For example: Managed System A has IP address 143.185.63.176, console System B has two IP addresses 143.185.63.172 and 192.16.57.230. System A can communicate with System B through 143.185.63.172, but it can't communicate through the second IP address. DmiGetSubscriptionAddress can return only one of these addresses, which in some cases is the one that System A cannot access.
     
     Possible Workarounds:
     
     1. Provide connectivity to all client addresses.
        
        
     2. In the case where the client has more than one IP address, it can provide by itself the right IP address for the subscription without calling the DmiGetSubscriptionAddress() function. This Workaround can be used only if you have a single indication RPC server running on your system (single management application).
        
        That is, client System B has two IP addresses, 143.185.63.172 and 192.16.57.230.

        Instead of calling to the DmiGetSubscriptionAddress() function, you can subscribe with the right IP address, that is, 143.185.63.172. (In this case, you don't have to provide an end point. Since you don't provide an end point, only one indication server per system will receive the indication.)
        
        

   • Due to the DCE RPC limitations, the DMI RPC server does not accept more than 10 concurrent requests from DMI management applications. If more than ten concurrent requests are submitted, the Service Provider returns the DMIERR_RPC_SERVER_TOO_BUSY error code.

     A similar problem may occur when the SP itself is too busy and cannot serve the command inside the predefined time-out interval. In this case, the SP returns the DMIERR_SP_TOO_BUSY error.

     In both cases, the recommended Workaround is to retry the command after a reasonable delay.
     
     

   • The MIF parser does not check <DATE> value format validity while installing a new component, group or language mapping. However, DmiSet commands do check <DATE> value format.
     
     
   • The DMI Service Provider's database grows with the addition of each new element (Component, Language, Group or Row); however, this space is not recovered when deleting these elements. To recover this space, invoke the Service Provider, WIN32SL.EXE, with the shrink command line option (-r). Note that database access time may increase as its size grows.
     
     
   • The DMI Specification Version 2.00 states that the Subscriber Address can be up to 1024 characters. Since the Service Provider database does not support variables greater than 508 bytes in size, the Subscriber Address size has been limited to 508 bytes in the SP MIF (WIN32SL.MIF).
     
     
   • The SP does not permit the installation of MIF files that contain group and/or attribute IDs equal to -1.
     
     
   • Activating the Advanced Power Management on a Windows 95 system causes problems in the DCE RPC and the Service Provider does not respond to RPC calls in some transports (TCP/IP, NetBIOS).
     
     
   • National Language Support in the Service Provider:
     
     
     1. The only translatable strings are meta-strings: names, descriptions, pragmas and enumerations. DmiList commands return strings in the session language if possible or in the component default language with error code DMIERR_DEFAULT_LANGUAGE_RETURNED.
        
        Note: Previous versions of the SP may return an invalid number of terminating nulls in the string if the session language is not found.
        
        
     2. Attribute values (keys and non-keys) are encoded in the default (first) language of the component. Component instrumentation may support more than one language encoding; however, only the default language is requested by the SP for each component. In this way, the SP ensures that static and dynamic attribute values have the same encoding. All requests to get/set attribute values return/change the initial instance of the attribute.
        
        Note: Previous versions of the SP do not guarantee that component instrumentation is called with the default component language.
        
        
     3. The SP does not check DisplayStrings for language encoding compliance. The iso8859-1 string should be terminated with one zero byte; UNICODE strings have an even number of bytes, the last two of which are zeros. It is the management application's responsibility to ensure proper encoding of input parameters.
        
        
     4. The SP modifies strings passed between DMI 1.0 and DMI 2.0 entities. It adds/removes a null character based on the default language encoding of the component.
        
        
     5. The default session language is en|US|iso8859-1. A management application can change the session language, using the DmiSetConfig function. It is possible to call this function with a partial language string. In this case, the SP fills in all missing fields from the en|US|iso8859-1 language string.
   
   8) Appendix A: Controlling the Service Provider RPC Functionality
   ----------------------------------------------------------------------------------------------
   
   The capability to control the RPC functionality of the Service Provider has been added. By default the RPC functionality of the Service Provider is enabled when the Service Provider is started. It is also possible to start the Service Provider with its RPC functionality disabled. To do this, set the registry value of Enable at Startup to 0. This value is located under the registry key:
   
   HKEY_LOCAL_MACHINE\SOFTWARE\Intel\DMI 2.0 SDK\Current Version\ Service Provider\Remoting.
   
   When the RPC functionality is disabled the Service Provider is NOT be available via RPC; it is only available via the local DMI 2.0 and the DMI 1.x interface. When the Service Provider is being started on a computer with no current connection to the network you might want to start it with the RPC functionality disabled, this avoids any automatic dial-up dialogs appearing during the Service Provider startup. At a future point in time when the computer is connected to the network it will be desirable to enable the RPC functionality. The capability to do this is supplied for the Service Provider running on Windows 95 systems only. The ability to control the RPC functionality of the Service Provider during the Service Provider execution is supplied by sending windows messages to the Service Provider (since when the Service Provider is an NT service it has no window - this capability is NOT available for the Service Provider running as an NT service).

   The constants for obtaining the Service Provider window and for the windows messages to be sent are located in the new include file spwndctl.h in the DMI include directory.

   Here's an example of the code for an application spcntl.exe that controls the Service Provider RPC functionality:

   spcntl start
   starts the Service Provider RPC functionality
   spcntl stop
   stops the Service Provider RPC functionality
   #include <windows.h>
   #include <stdio.h>
   /* include from the DMI include directory. All defined constants except for TRUE and FALSE 
   come from 
       this file  */
   #include <spwndctl.h>
   void Usage (char * progname)
   {
       printf ("Usage is:\n");
       printf ("%s start\n", progname);
       printf ("or\n");
       printf ("%s stop\n", progname);
   }
   BOOL static ControlSpRpcServer (HWND dmiSpHwnd, UINT rpcCtlMessage, WPARAM 
   wParam)
   {
       LONG retVal;
       BOOL success = TRUE;
       retVal = SendMessage (dmiSpHwnd, rpcCtlMessage, wParam, 0);
       switch (retVal)
       {
           case 0:
             printf ("Unable to SendMessage  lastErr %d\n", GetLastError ());
             success = FALSE;
             break;
           case SP_CONTROL_NO_ERROR:
             if (wParam == QUERY_SP_RPC_SERVER_STATE)
             {
                 printf ("UnExpected return value from SendMessage %d\n", retVal);
             }
             else
             {
                 printf ("SP successfuly processed the request\n");
             }
             break;
           case SP_CONTROL_ERROR:
             printf ("An error occured in the SP while processing the request\n");
             success = FALSE;
             break;
           case SP_CONTROL_BUSY:
             printf ("The SP is busy with a different request - try again later\n");
             break;
           case SP_RPC_STATUS_ENABLED:
             printf ("The status of the SP rpc server is enabled\n");
             break;
           case SP_RPC_STATUS_DISABLED:
             printf ("The status of the SP rpc server is disabled\n");
             break;
             
           default:
             printf ("UnExpected return value from SendMessage %d\n", retVal);
             success = FALSE;
             break;
       }
   	return (success);
   }
      
   int main (int argc, char *argv[])
   {
       UINT rpcCtlMessage = 0;
       HWND dmiSpHwnd = NULL;
       BOOL success;
       WPARAM wParam;
       if (argc != 2)
       {
           Usage (argv[0]);
           exit (0);
       }
       if (stricmp ("start", argv[1]) == 0)
       {
           wParam = ENABLE_SP_RPC_SERVER;
       }
       else if (stricmp ("stop", argv[1]) == 0)
       {
           wParam = DISABLE_SP_RPC_SERVER;
       }
       else
       {
           Usage (argv[0]);
           exit (0);
       }
       
       /* Get handle to SP window */   
       dmiSpHwnd = FindWindow(WIN32SL_CLASS, WIN32SL_WINDOW_NAME);
       if (dmiSpHwnd == NULL)
       {
           printf ("Unable to find SP window  lastErr %d\n", GetLastError ());
           exit (0);
       }
       /* Get the message number of the SP control message */
       rpcCtlMessage = RegisterWindowMessage (WIN32SL_CONTROL_MSG_NAME);
       if (rpcCtlMessage == 0)
       {
           printf ("Unable to RegisterWindowMessage  lastErr %d\n", GetLastError ());
           exit (0);
       }
       success 
         = ControlSpRpcServer (dmiSpHwnd, rpcCtlMessage, wParam);
       if (!success)
       {
           exit (0);
       }
       printf ("Now query the status of the SP rpc server\n");
       success 
         = ControlSpRpcServer (dmiSpHwnd, rpcCtlMessage, 
   QUERY_SP_RPC_SERVER_STATE);
       return (0);
   }
   

   
   
   
   * Legal Information © 1998 Intel Corporation